@miq-bot add_label bug
Cc @Ladas @jameswnl @agrare

@jameswnl it seems it is failing in one test: https://travis-ci.org/ManageIQ/manageiq/jobs/391635305

I'm not sure how this error happens, local test is ok.
Is this check necessary? That class exists and is identical

@jameswnl @slemrmartin looks to me that the correct STI class should be ManageIQ::Providers::EmbeddedAutomationManager::InventoryRootGroup

@jameswnl @slemrmartin actually, to be consistent with other providers we should be using ManageIQ::Providers::EmbeddedAnsible::AutomationManager::InventoryRootGroup

Also its seems like we do have a lot of empty abstract classes there, so the ansible codebase would deserve a cleanup. :-)

@Ladas I can't figure out why this line would resolve to ManageIQ::Providers::AutomationManager::InventoryRootGroup

The others in the same file are properly resolving to ManageIQ::Providers::EmbeddedAnsible::AutomationManager::*

@jameswnl it seems like problem is in spec, not in my code, right?
So I would like to change spec to :type => manager_class::InventoryRootGroup.name like all other specs.

But I don't know how to simulate travis error, do you know?

@jameswnl @Ladas what class do we expect these to be as a result of a refresh today?

@slemrmartin yeah, I think so. But the problem I have is same as you - don't know how to reproduce travis error locally.

travis fixed in ManageIQ/manageiq-providers-ansible_tower#104
but it depends on this PR.
@agrare what next?

@slemrmartin @Ladas @jameswnl I think the problem is that the old interface was setting the STI class incorrectly. Even though it is "wrong" without a data migration to correct it the new interface should be compatible with the old interface.

This new interface should set the same STI classes as the old one even if the old one wasn't correct. If you put a PR in to fix existing data then we can fix it here.

@agrare do you want to see Rails in action? :)
"ManageIQ::Providers::EmbeddedAnsible::AutomationManager::InventoryRootGroup".safe_constantize ==

• ManageIQ::Providers::AutomationManager::InventoryRootGroup on dev
• ManageIQ::Providers::EmbeddedAutomationManager::InventoryRootGroup in travis

@jameswnl because InventoryRootGroup is the only inventory collection which doesn't have class under all namespaces, it's the only IC where ManageIQ::Providers::AutomationManager::InventoryRootGroup have to be specified explicitely.

A weird behaviour I wrote above is performed also for new method. For EmbeddedAnsible it was unpredictable which class is chosen by autoloader.

So I think these specs worked only with some luck before.

Checked commits slemrmartin/manageiq@617b637~...e67709b with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0
3 files checked, 0 offenses detected
Everything looks fine. 👍